Methods and apparatus for resolving data inconsistencies in an IMS network

ABSTRACT

A Serving Call Session Control Function, S-CSCF, within an IP Multimedia Subsystem, IMS, core network. Notifications are sent to a Home Subscriber Server, HSS, of the IMS core network, indicating IMS registration state changes of users. Delivery failure of a notification of an IMS registration state change sent to a HSS and relating to a given user is detected. An association between an identifier of the given user and an indication of said delivery failure is stored in order to indicate a loss of IMS registration state synchronization for the given user between the S-CSCF and the HSS. An event requiring an IMS registration state change for the user is detected. A determination is made that a delivery failure indication associated with the user&#39;s identifier is stored. The HSS is notified indicating the required IMS registration state change and of a previous loss of the IMS registration state synchronization.

TECHNICAL FIELD

The present invention relates to methods and apparatus for resolvingdata inconsistencies within an IP Multimedia Subsystem network, and inparticular for handling data inconsistencies arising between a ServingCall Session Control Function and a Home Subscriber Server due, forexample, to a link failure.

BACKGROUND

IP Multimedia Subsystem (IMS) is the technology defined by the ThirdGeneration Partnership Project (3GPP) to provide IP Multimedia servicesover mobile communication networks. The architecture and generalfeatures of the IMS are described generally in 3GPP specification TS23.002 and, in more detail, in TS 23.228. IMS provides key features toenrich the end-user person-to-person communication experience throughthe integration and interaction of services. IMS allows new richperson-to-person (client-to-client) as well as person-to-content(client-to-server) communications over an IP-based network. The IMSmakes use of the Session Initiation Protocol (SIP) to set up and controlcalls or sessions between user terminals (or user terminals andapplication servers). The Session Description Protocol (SDP), carried bySIP signalling, is used to describe and negotiate the media componentsof the session. Whilst SIP was created as a user-to-user protocol, IMSallows operators and service providers to control user access toservices and to charge users accordingly. Other protocols are used formedia transmission and control, such as Real-time Transport Protocol andReal-time Transport Control Protocol (RTP/RTCP).

The IMS is logically structured into a so-called “core network” layer(implemented by functional entities which are briefly described below),and a so-called “service layer” (essentially comprising “applicationservers” arranged to provide services to user terminals (referred tohereinafter as User Equipment (UE)) connected via the IMS, and/orarranged to mediate in the provision of services by executing specificservice-based logic, such as to divert an incoming multimedia session incertain circumstances).

Of particular interest here are the Serving Call Session ControlFunction (S-CSCF) and the Home Subscriber Server (HSS) which are bothpresent within the IMS core network. The S-CSCF performs the sessioncontrol services for a UE and maintains a session state according to the(SIP) signalling exchanged with a UE for supporting the servicesoriginated and/or terminated by the UE. The S-CSCF can also communicatewith “application server/s” of the IMS “service layer” to handle aservice for an UE. Further details of the functionality of a S-CSCF aregiven in chapter 4.6.3 of 3GPP specification TS 23.228. The HSS is themaster database for storing data for a given user. It is the entitycontaining the subscription-related information to support the networknodes actually handling communications (e.g. calls, sessions, etc) witha UE registered for said user. For example, the HSS provides support tothe nodes implementing Call session functionalities in order to completethe routing/roaming procedures by solving authentication, authorization,naming/addressing resolution, location dependencies, etc. Furtherdetails of the functionality of the HSS are given in chapter 4.1.1.1 of3GPP specification TS 23.002.

It is noted that, within the IMS, a user may have one of three differentregistration states. These are:

-   -   “Registered”—a contactable address is registered for the user;        the user has an S-CSCF allocated that maintains the user profile        which allows the user to initiate and terminate        telecommunication services (such as making and receiving calls).    -   “Not Registered”—no contactable address information is held for        the user by the IMS, nor is an S-CSCF allocated to the user. The        user cannot initiate or terminate services from/to any terminal        (UE) since no user terminal is currently registered for the        user. Therefore, no services are available for the user. The        user might, however, receive a terminating service (e.g. a        terminating call) which can lead—according to existing IMS        procedures—to an S-CSCF being allocated to the user to keep the        user profile. This allows the execution of so-called        “unregistered services” (e.g. diversion to a server of a        terminating service, such as diversion of an incoming voice call        to a voice mail server) via the allocated S-CSCF, and changes        the user status to “Unregistered” (see below description of the        “Unregistered” state).    -   “Unregistered”—no contactable address information is held for        the user (e.g. there is no IP address of a UE registered for the        user which is usable to contact the user). An S-CSCF is however        allocated to the user and the S-CSCF maintains the user profile.        So-called “unregistered services” are available to the user.        These unregistered services allow a terminating service        addressed to a user to be processed when the user has no UE        terminal currently registered within the IMS which can be        addressed from the IMS for the terminating service. Therefore, a        user profile, held by the S-CSCF, can comprise information to        process a terminating call addressing an identifier of the user        in such a way that it is held (i.e. terminated) by a voice mail        server.

In the event of a UE being powered off, or due to a loss of mobilenetwork coverage, a user may be moved from a Registered to a NotRegistered state. Thereafter, due, e.g. to some event such as aterminating service request, the user may be moved from the NotRegistered state to the Unregistered state. To achieve this, the S-SSCFwill obtain user profile data from the HSS. After some timeout periodduring which no further event occurs, the user will be moved back to theUnregistered state and the S-CSCF will delete the user's profile data.

Whilst the 3GPP organisation originally proposed the IMS in the contextof mobile networks, it is noted that the IMS also finds application inrespect of fixed access networks. A typical operator architecture mayutilise the IMS to seamlessly deliver services over both a fixed and amobile network.

The 3GPP organisation has standardized so-called “IMS RestorationProcedures” in the 3GPP specification TS 23.380 in order to specify howto handle a service interruption due to failures in the IMS corenetwork. In particular, the specification considers the case where anS-CSCF assigned to serve a UE (after a registration of the UE) becomesunreachable, e.g. due to internal error, or looses user data, e.g. dueto a restart. The restoration procedures envisaged by 3GPP allow theS-CSCF to store and retrieve registration user data such that, when auser registers successfully in the IMS network via a UE, the primarilyassigned S-CSCF stores all the data needed to serve the user in the HSS.In the event of a failure of the primarily assigned S-CSCF, another(secondary) S-CSCF may retrieve the saved data and continue serving theusers in a way that is transparent to the end users.

The proposed restoration procedures require both that the HSS itself,and the IP connectivity between the S-CSCF and the HSS, are continuouslyavailable. As such, there is a possibility that both temporary andpermanent failures in the HSS and the interconnecting link will resultin the restoration procedures failing to restore user services. Tomitigate against this problem, the HSS is required not to trust userrelated information sent to it by S-CSCF if there is an inconsistencydetected between the sent user data and the user data already stored inthe HSS. The HSS, upon detecting such an inconsistency, mustre-establish the old data into the S-CSCF (i.e. the so called“restoration information” which includes the old contact address, e.g.IP address, of the user corresponding to the old registration. However,this approach can result in inappropriate service delivery to the user.For example, when the user is Not Registered with the S-CSCF but isrecorded as Registered in the HSS, re-registration of the user in theS-CSCF by the HSS may cause the S-CSCF to attempt to deliver aterminating service to an obsolete or even re-assigned “contact”address, rather than delivering an Unregistered service, e.g. voicemail.

SUMMARY

According to a first aspect of the present invention there is providedapparatus configured to operate as a Serving Call Session ControlFunction, S-CSCF, within an IP Multimedia Subsystem, IMS, core network.The apparatus comprises an interface for sending to a Home SubscriberServer, HSS, of the IMS core network, notifications indicating IMSregistration state changes of users, and a detector for detectingdelivery failure of a notification of an IMS registration state changesent to a HSS and relating to a given user. The apparatus furthercomprises a memory and memory controller for storing in said memory anassociation between an identifier of said given user and an indicationof said delivery failure in order to indicate a loss of IMS registrationstate synchronisation for said given user between the S-CSCF and theHSS. There is further provided an event handler for detecting an eventrelating to said given user, the event requiring an IMS registrationstate change for the user, determining that said memory currently storesa delivery failure indication associated with the user's identifier, andcausing said interface to send a further notification to the HSS, thefurther notification including both an indication of the required IMSregistration state change and an indication of a previous loss of IMSregistration state synchronisation for the user between the S-CSCF andthe HSS.

Embodiments of the may prevent communication failures between the S-CSCFand the HSS resulting in a subsequent user service failures. Inparticular, the terminating services may be correctly handled on behalfof an Unregistered user.

The detector may be configured to detect failure of a notificationindicating an IMS registration change, for said given user, from aRegistered state to a Not Registered state, with said event handlerbeing configured to detect an event requiring an IMS registrationchange, for said given user, from the Not Registered state to anUnregistered state. This event may comprise the receipt by the apparatusof a terminating service request in respect of said given user.

The interface may be further configured to receive, from the HSS, aresponse to the further notification, with the memory controller beingresponsive to said response to delete in said memory the deliveryfailure indication associated with an identifier of the user. Theresponse may includes a user profile with the event handler beingconfigured to use the user profile to progress the event.

According to a second aspect of the present invention there is providedapparatus configured to operate as a Home Subscriber Server, HSS, withinan IP Multimedia Subsystem, IMS, core network. The apparatus comprises amemory for storing users' IMS registration states, and an interface forreceiving from a Serving Call Session Control Function, S-CSCF, of theIMS core network, notifications indicating IMS registration statechanges of users to new IMS registration states. The apparatus furthercomprises a state synchronisation handler for determining that anotification received from the S-CSCF contains an indication of aprevious loss of IMS registration state synchronisation for a given userbetween the S-CSCF and the HSS, and for responding by updating the givenuser's IMS registration state in the memory to the new IMS registrationstate contained in the received notification.

The state synchronisation handler may be configured to determine a) thata notification indicates that the current IMS registration state forsaid given user is Unregistered, and b) that said memory currentlyrecords the user state as Registered, the state synchronisation handlerbeing configured to update the memory to record the user's IMSregistration state to Unregistered.

The state synchronisation handler may be configured, upon determiningthat a notification contains an indication of a previous loss of IMSregistration state synchronisation, to cause said interface to send aresponse to the S-CSCF including a user profile.

According to a third aspect of the present invention there is provided amethod of handling a communication failure between a Serving CallSession Control Function, S-CSCF, and a Home Subscriber Server, HSS, ofan IP Multimedia Subsystem, IMS, network.

The method comprises, at the S-CSCF, detecting delivery failure of anotification sent by the S-CSCF to the HSS and relating to an IMSregistration state change for a given user, and recording an indicationof the delivery failure in association with said given user in order toindicate a loss of IMS registration state synchronisation for the givenuser between the S-CSCF and the HSS. The method further comprisesdetecting an event relating to said given user, the event requiring anIMS registration state change for the user to a new state, determiningthat a delivery failure indication is currently associated with theuser, and sending a further notification to the HSS, the furthernotification including both an indication of the required IMSregistration state change and an indication of a previous loss of IMSregistration state synchronisation for the user between the S-CSCF andthe HSS.

The method further comprises, at the HSS, receiving said furthernotification, determining that the notification includes said indicationof a previous loss of IMS registration state synchronisation for theuser, and updating an IMS registration state for the given user to saidnew IMS registration state included within the notification.

The step of detecting delivery failure may comprise detecting deliveryfailure of a notification indicating an IMS registration change, forsaid given user, from a Registered state to a Not Registered state. Thestep of causing said interface to send a further notification to the HSSis triggered by detection of an event requiring an IMS registrationchange, for said given user, from the Not Registered state to anUnregistered state. Said event may comprises the receipt by the S-CSCFof a terminating service request in respect of said given user.

Further aspects of the present invention are set out in the appendedclaims.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates a procedure within the IMS for handling IMSregistration state, but which fails due to a temporary communicationfailure between the S-CSCF and the HSS;

FIG. 2 illustrates an improved procedure within the IMS for handling IMSregistration state and which is able to restore synchronisation lost dueto a temporary communication failure between the S-CSCF and the HSS;

FIG. 3 illustrates schematically an S-CSCF configured to participate inthe procedure of FIG. 2;

FIG. 4 illustrates schematically an HSS configured to participate in theprocedure of FIG. 2; and

FIG. 5 is a flow diagram further illustrating the procedure of FIG. 2.

DETAILED DESCRIPTION

Failure handling and recovery is critical when designing andimplementing communication networks in order to both maximise operatorrevenue and enhance customer experience. With this in mind, the 3GPPorganisation has specified a number of failure handling and recoverymechanisms for the IP Multimedia Subsystem (IMS).

3GPP TS 23.380 (section 4.3.2) describes a scenario where the HSSdetermines that the S-CSCF has lost its user data and, as a consequence,invokes restoration procedures. Consider the scenario illustrated inFIG. 1 and which assumes that a user has previously registered with theIMS using a contact IP address (e.g. contact_1). The scenario isassociated with the following steps:

-   -   1. There is a temporary connection failure between the S-CSCF        assigned to serve the user and the HSS (e.g. a problem has        occurred in the IP backbone routing, a diameter link has gone        down, or a hardware fault has occurred that causes the HSS to be        temporarily out of service and not responding).    -   2-3. While the failure persists, the user's contactable address        becomes unavailable. This might arise for example because the        user has powered off the UE, or because the UE looses access        network coverage (in the case of a mobile UE). The S-CSCF        determines this change in user status and as a result        de-registers the user from the S-CSCF (e.g. chapters 5.4.1.4.1        or 5.4.1.5 of 3GPP TS 24.229 disclose details of the data that        the S-CSCF should delete in this situation).    -   4. The S-CSCF sends a message to inform the HSS of this event,        asking the HSS to de-register the user and remove the        restoration information (e.g. to disassociate the contactable        address from the user identifier(s) served by the S-CSCF) stored        in the HSS. Specifically, the S-CSCF sends to the HSS a        Cx-Server-Assignment-Request (e.g. with TIMEOUT_DEREGISTRATION).        Successful delivery of this message to the HSS would result in        the HSS considering the user as “Not Registered”. However, due        to the noted failure, this message is not in fact delivered to        the HSS.    -   5-7. After a certain time and/or number of unacknowledged        resending attempts, the S-CSCF gives up its attempt to send the        message (the timer to establish the TCP socket may be        configurable). The HSS however still has the user status        recorded as “Registered” and therefore contactable via the        S-CSCF for any terminating service. The S-CSCF on the other hand        has deleted the corresponding registration data, i.e. the S-CSCF        does not have any registration data at all for the user, which        means that the user is not found in its internal database.    -   8. Communication between the S-CSCF and the HSS is restored.    -   9. A terminating service, e.g. an incoming call, directed to the        user is received. For example, the S-CSCF receives a SIP        protocol INVITE message indicating an identifier (e.g. IMS        Public User Identifier, IMPU, and or IMS Private User        Identifier, IMPI) of the destination user.    -   10. The S-CSCF informs the HSS that the user is Not Registered        and has received a call (e.g. by sending a Cx-SAR DIAMETER        message comprising an “Unregistered_User” indication contained        within the server assignment type AVP), in order to retrieve the        user profile, move the user to an Unregistered state, and        execute appropriate Unregistered services (e.g. forward the        terminating service to a voice mail server).    -   11. The HSS detects an inconsistency. Specifically it detects        that the data currently held by the HSS for the user records the        user as Registered and currently assigned to that same S-CSCF,        whist the message received from the S-CSCF indicates that the        user is not currently registered within the S-CSCF (i.e.        “Unregistered User”). Therefore, according to the currently        standardized procedures in 3GPP TS 29.228 (e.g. section 6.1.2.1,        and in particular page 19 first paragraph), the request of step        10 is rejected by the HSS. The HSS informs the S-CSCF of the        rejection (Cx-SAA with diameter_“error_in_assignment_type”).        Moreover, as a result of said standardized procedures, the HSS        returns the currently registered contactable address (contact_1)        to the S-CSCF (i.e. as a part of the so called “restoration        information”), and the S-CSCF subsequently records the user with        a registration state as “Registered” with the received        contactable address (i.e. as stated by the “restoration        information” received from the HSS).    -   12. The S-CSCF progresses the call towards the user. The call        will be unsuccessful of course as the user is no longer present        at the supposedly contactable address (e.g. contact_1). Whilst        the called user will not be troubled directly by this failure—he        or she has, for example, switched off the UE or lost network        coverage—a problem will arise if contact_1 is now registered in        respect of another user, i.e. the call is made to the wrong        user. Even if contact_1 has not been reassigned to another user,        the experience of the calling user will be poor as Unregistered        services, e.g. voice mail, will not be executed on behalf of the        called user as the S-CSCF has now wrongly recorded the user as        Registered with “obsolete” information.

A similar problem can arise when the S-CSCF receives a new IMSregistration request for a user, following an earlier failure to delivera de-registration notification from the S-CSCF to the HSS. As the S-CSCFdoes not have any data for the user, it will send a message to the HSSindicating that this is an initial registration (i.e. there is nocontact address associated with the user). The HSS will howeverdetermine that it does have a contactable address stored for the user(which is not valid, since it should have been deleted previously), andwill inform the S-CSCF about this. The S-CSCF will then wronglyassociate the invalid contact address provided by the HSS with the user.

It is proposed here to overcome this problem by first enabling theS-CSCF to indicate to the HSS the reliability of the informationpreviously sent by the S-CSCF, when notifying the HSS of some new event.In other words, the S-CSCF will make the HSS aware that the informationstored by the HSS for the user in question is not current, since theS-CSCF did not previously succeed in informing the HSS about a previousevent.

According to this solution, an S-CSCF that fails to communicate aderegistration event of a user to the HSS will set a mark, indicating“pending to sync state with HSS”, in respect of one or more useridentifiers of the concerned user (e.g. the S-CSCF adds the useridentifier into a “pending to sync state with HSS” list). When it isrequired to send a further communication message from the S-CSCF to theHSS in respect of the user (caused, for example, by the reception by theS-CSCF of a protocol message indicating a terminating service towardssaid user), the S-CSCF includes within the message a new indicationdepending on the existence of the mark. Subsequently, upon reception ofthe new indication from the S-CSCF, the HSS considers its owninformation about this user to be obsolete (i.e. it does not considerthe S-CSCF communication as an error due to a restart on the S-CSCF) andreplies to the S-CSCF by downloading to it the corresponding userprofile. The HSS does not force the S-CSCF to restore obsolete data(i.e. the so-called “restoration information” including the old contactaddress). In addition, the HSS updates the status according to theS-CSCF indication (e.g. it replaces the status Registered withUnregistered and the associated obsolete data is removed). This willallow the S-CSCF to process a terminating service request for the useraccording to the Unregistered state service (e.g. diverting an incomingcall to a voice mail server). The HSS status is then synchronized sothat the user data is consistent again between S-CSCF and the HSS, i.e.both record the user as Unregistered.

FIG. 2 illustrates this alternative scenario including the followingsteps:

-   -   1-5. These steps correspond to steps 1-6 of FIG. 1, except that        step 3 of FIG. 1 is not performed, i.e. the user is not removed        from the S-CSCF database.    -   6. The S-CSCF removes all data it has stored concerning the user        (including data specific to the UE, such as its previously        registered “contact” address). Alternatively, the data may be        maintained but marked as obsolete. The user is now in a Not        Registered state. However, according to the present solution,        the S-CSCF stores one or more identifiers of the user (which can        comprise identifier/s of the UE) in association with an        indication of a delivery failure, thereby indicating a loss of        IMS registration state synchronization for the user between the        S-CSCF and the HSS. This can be achieved, for example, by        causing the S-CSCF to add the user identifier(s) that was(were)        registered through the UE to a “pending to sync state with HSS”        list. The user identifier can comprise the IMPU of the user, the        IMPI of the user, or the IMPU/IMPI pair (e.g. SIP-URI, TEL URI,        etc).    -   7. This step corresponds to step 7 of FIG. 1. [NB. The S-CSCF        now awaits any traffic activity associated with the user to        inform the HSS of the inconsistency.]    -   8-9. After communication with the HSS has been restored, the        S-CSCF receives a terminating service request. The S-CSCF        determines, based upon the called user identifier, that this        user is currently in a Not Registered state but detects that the        user identifier is stored within the “pending to sync state with        HSS” list.    -   10. As in step 10, FIG. 1, the S-CSCF then seeks to retrieve the        user profile from the HSS to allow the S-CSCF to execute        Unregistered services for the called user by sending a DIAMETER        message “Server Assignment Request” (SAR) to the HSS. Again, the        SAR message conveys a registration state indication indicating        “Unregistered_User”. However, the message also includes a new        Attribute Value Pair (AVP) described in detail below. The new        AVP informs the HSS of a previous failure to synchronize the        registration state of this user between the S-CSCF and the HSS,        so that any user state (e.g. registration state) and restoration        information (e.g. the UE's contact address/es) that the HSS has        currently stored in respect of this user is not up to date,        since there was a previous, failed attempt (by the S-CSCF) to        update the information in the HSS.    -   11. The HSS, conditioned by the content of the SAR message,        updates the user state of this user to Unregistered and removes        the previously registered contact address (restoration        information).    -   12. The relevant user profile is returned from the HSS to the        S-CSCF in a diameter Server-Assignment-Answer message to allow        the further execution by the S-CSCF of the received terminating        service (as well as the further execution of future terminating        services received in respect to the user whilst still in        “unregistered” state). The reply sent in this step 12 by the HSS        is, therefore, not the same as the one sent in the corresponding        step 11 of FIG. 1. In particular, and as a result of the HSS        processing the state synchronization failure indication from the        S-CSCF, the HSS determines that it should not re-establish        “restoration information” in respect of this user. The reply        sent from the HSS does not contain “restoration information”        (i.e. it does not include the old “contactable address”), but        rather contains the user profile data usable for allowing        further execution by the S-CSCF of a terminating service.    -   13. Upon reception of successful response from HSS, the S-CSCF        resets the “pending to sync HSS status” flag in respect to the        identifier/s of this user, i.e. it removes the user identifier        from the “pending to sync state with HSS” list.

Referring to step 10, the indication of a loss of user statussynchronisation can be included in the SAR by means of a new andoptional Boolean diameter AVP. The simple presence of the AVP within anSAR will trigger the new procedure in the HSS. The new AVP is referredto here as a “Resynchronization-Indication” AVP and has two possiblevalues:

-   -   FALSE—This value indicates that the HSS registration information        for the user identifier is to be trusted, i.e. there are no        pending or failed requests from the S-CSCF to update the HSS.        This is the default value when the AVP is absent.    -   TRUE—This value indicates that the HSS registration information        for the identifier is not to be trusted, i.e. there are pending        or failed requests from the S-CSCF to update the HSS. The HSS        shall update its registration status and relevant information in        accordance with the current Server-Assignment-Request command.

Referring now to FIG. 3, this illustrates schematically an apparatus 1configured to operate as a Serving Call Session Control Function,S-CSCF, within an IP Multimedia Subsystem, IMS, core network. It will beappreciated that this apparatus may comprise a combination ofprocessors, memories, etc, configured using appropriate software toimplement certain of the functionality described above. Moreparticularly, the apparatus comprises an interface 2 for sending to aHome Subscriber Server, HSS, of the IMS core network, notificationsindicating IMS registration state changes of users. A detector 3 isprovided for detecting delivery failure of a notification of an IMSregistration state change sent to the HSS and relating to a given user.

A memory 4 and memory controller 5 are provided. The latter is arrangedto store in the memory 4 an association between an identifier of thegiven user and an indication of the delivery failure. The memorytherefore indicates, for this user and other affected users, a loss ofIMS registration state synchronisation between the S-CSCF and the HSS.The apparatus further comprises an event handler 6 for detecting anevent relating to the given user, where this event requires an IMSregistration state change for the user. The event handler 6 is able todetermine that the memory 4 currently stores a delivery failureindication associated with the user's identifier. Thereafter, it causesthe interface 2 to send a further notification to the HSS, the furthernotification including both an indication of the required IMSregistration state change and an indication of a previous loss of IMSregistration state synchronisation for the user between the S-CSCF andthe HSS.

FIG. 4 illustrates schematically apparatus 7 configured to operate as aHome Subscriber Server, HSS, within an IP Multimedia Subsystem, IMS,core network. Again, it will be appreciated that this apparatus maycomprise a combination of processors, memories, etc, configured usingappropriate software to implement certain of the functionality describedabove.

The apparatus (HSS) comprises a memory 8 for storing users' IMSregistration states, as well as an interface 9 for receiving from aServing Call Session Control Function, S-CSCF, of the IMS core network,notifications indicating IMS registration state changes of users to newIMS registration states. The apparatus further comprises a statesynchronisation handler 10 for determining that a notification receivedfrom the S-CSCF contains an indication of a previous loss of IMSregistration state synchronisation for a given user between the S-CSCFand the HSS. The state synchronisation handler 10 is configured torespond to such a determination by updating the given user's IMSregistration state in the memory 8 to the new IMS registration statecontained in the received notification.

Either or both the S-CSCF 1 illustrated in FIG. 3 and the HSS 7illustrated in FIG. 4 can be implemented by apparatus having behaviour(e.g. comprising, among other things: the processing of signals receivedfrom other apparatus, the sending of signals to other apparatus and thecontent of sent signals, as well as the management of stored informationaccording to—among other things—the content of signals received fromother apparatus) controlled by one or more processors arranged toexecute computer program instructions. In such implementations, each ofthe apparatus may comprise: a computer program instruction store (e.g. amemory incorporated by the apparatus), and a processor reading andexecuting the stored computer program instructions. Therefore, accordingto this implementation embodiment, the behaviour of some of thefunctional modules illustrated by FIG. 3 in respect to a S-CSCF (e.g.the interface 2, the detector 3, the memory controller 5, the eventhandler 6) or by FIG. 4 in respect to a HSS (e.g. the interface 9, thestate synchronization handler 10) can be driven by computer programinstructions that, when executed by processor/s within the S-CSCF orwithin the HSS, cause the S-CSCF or the HSS to behave according to anyof the embodiments described herein.

Referring now to FIG. 5, this is a flow diagram illustrating the methodof handling a communication failure between a Serving Call SessionControl Function, S-CSCF, and a Home Subscriber Server, HSS, of an IPMultimedia Subsystem, IMS, network. The S-CSCF firstly (51) detectsdelivery failure of a notification sent by the S-CSCF to the HSS andrelating to an IMS registration state change for a given user. Thedelivery failure is then recorded (S2), at the S-CSCF, in associationwith the user in order to indicate a loss of IMS registration statesynchronisation for the user between the S-CSCF and the HSS.

Subsequently, the S-CSCF detects (S3) an event relating to the sameuser, the event requiring an IMS registration state change for the userto a new state. The S-CSCF then determines (S4) that a delivery failureis currently associated with the user. In response (S5) the S-CSCF sendsa further notification to the HSS, the further notification includingboth an indication of the required IMS registration state change and anindication of a previous loss of IMS registration state synchronisationfor the user between the S-CSCF and the HSS.

This further notification is received at the HSS (S6), and the HSSdetermines (S7) that the notification includes the indication of aprevious loss of IMS registration state synchronisation for the user. Inresponse, the HSS updates (S8) an IMS registration state for the user tothe new IMS registration state included within the notification.

It will be appreciated by the person of skill in the art that variousmodifications may be made to the above described embodiments withoutdeparting from the scope of the invention. By way of example, it isnoted that the embodiment described above is concerned with a loss ofuser state synchronisation whereby the S-CSCF maintains a status of NotRegistered and the HSS maintains a status of Registered. However, theinvention may also be used to resolve other user state inconsistencies.

The invention claimed is:
 1. A Serving Call Session Control Function,S-CSCF, apparatus for use within an IP Multimedia Subsystem, IMS, corenetwork, the S-CSCF apparatus comprising: an interface for sending to aHome Subscriber Server, HSS, of the IMS core network, notificationsindicating IMS registration state changes of users; a detector fordetecting delivery failure of a notification of an IMS registrationstate change sent to a HSS and relating to a given user; a memory andmemory controller for storing in said memory an association between anidentifier of said given user and an indication of said delivery failurein order to indicate a loss of IMS registration state synchronizationfor said given user between the S-CSCF and the HSS; and an event handlerfor: detecting an event relating to said given user, the event requiringan IMS registration state change for the user; determining that saidmemory currently stores a delivery failure indication associated withthe user's identifier; and causing said interface to send a furthernotification to the HSS, the further notification including both anindication of the required IMS registration state change and anindication of a previous loss of IMS registration state synchronizationfor the user between the S-CSCF and the HSS.
 2. The apparatus of claim1, wherein said detector is configured to detect failure of anotification indicating an IMS registration change, for said given user,from a Registered state to a Not Registered state, and said eventhandler is configured to detect an event requiring an IMS registrationchange, for said given user, from the Not Registered state to anUnregistered state.
 3. The apparatus of claim 2, wherein said eventcomprises the receipt by the apparatus of a terminating service requestin respect of said given user.
 4. The apparatus of claim 1, wherein saidevent comprises the receipt by the apparatus of a terminating servicerequest in respect of said given user.
 5. The apparatus of claim 1,wherein said interface is configured to operate according to theDiameter protocol, and said notifications are conveyed within ServerAssignment Request, SAR, messages.
 6. The apparatus of claim 5, whereinsaid event handler is configured to include an indication of a previousloss of IMS registration state synchronization for the user as anAttribute Value Pair within an SAR message.
 7. The apparatus of claim 1,wherein said interface is further configured to receive, from the HSS, aresponse to said further notification, and wherein said memorycontroller is responsive to said response to delete in said memory thedelivery failure indication associated with an identifier of the user.8. The apparatus of claim 7, wherein said response includes a userprofile and said event handler is configured to use the user profile toprogress the event.
 9. A Home Subscriber Server, HSS, apparatus for usewithin an IP Multimedia Subsystem, IMS, core network, the HSS apparatuscomprising: a memory for storing users' IMS registration states; aninterface for receiving from a Serving Call Session Control Function,S-CSCF, of the IMS core network, notifications indicating IMSregistration state changes of users to new IMS registration states; anda state synchronization handler for determining that a notificationreceived from the S-CSCF contains an indication of a previous loss ofIMS registration state synchronization for a given user between theS-CSCF and the HSS, and for responding by updating the given user's IMSregistration state in the memory to the new IMS registration statecontained in the received notification.
 10. The apparatus of claim 9,wherein said state synchronization handler is configured to determine a)that a notification indicates that the current IMS registration statefor said given user is Unregistered, and b) that said memory currentlyrecords the user state as Registered, the state synchronization handlerbeing configured to update the memory to record the user's IMSregistration state to Unregistered.
 11. The apparatus of claim 9,wherein said interface is configured to operate according to theDiameter protocol, and said notifications are conveyed within ServerAssignment Request, SAR, messages.
 12. The apparatus of claim 11,wherein said state synchronization handler is configured to determinethat a notification contains an indication of a previous loss of IMSregistration state synchronization by detecting an Attribute Value Pairwithin an SAR message.
 13. The apparatus of claim 9, wherein said statesynchronization handler is configured, upon determining that anotification contains an indication of a previous loss of IMSregistration state synchronization, to cause said interface to send aresponse to the S-CSCF including a user profile.
 14. The apparatus ofclaim 10, wherein said state synchronization handler is configured, upondetermining that a notification contains an indication of a previousloss of IMS registration state synchronization, to cause said interfaceto send a response to the S-CSCF including a user profile.
 15. A methodof handling a communication failure between a Serving Call SessionControl Function, S-CSCF, and a Home Subscriber Server, HSS, of an IPMultimedia Subsystem, IMS, network, the method comprising: at theS-CSCF: detecting delivery failure of a notification sent by the S-CSCFto the HSS and relating to an IMS registration state change for a givenuser; recording an indication of the delivery failure in associationwith said given user in order to indicate a loss of IMS registrationstate synchronization for the given user between the S-CSCF and the HSS;detecting an event relating to said given user, the event requiring anIMS registration state change for the user to a new state; determiningthat a delivery failure indication is currently associated with theuser; and sending a further notification to the HSS, the furthernotification including both an indication of the required IMSregistration state change and an indication of a previous loss of IMSregistration state synchronization for the user between the S-CSCF andthe HSS; and at the HSS: receiving said further notification;determining that the notification includes said indication of a previousloss of IMS registration state synchronization for the user; andupdating an IMS registration state for the given user to said new IMSregistration state included within the notification.
 16. The method ofclaim 15, wherein said step of detecting delivery failure comprisesdetecting delivery failure of a notification indicating an IMSregistration change, for said given user, from a Registered state to aNot Registered state, and said step of causing said interface to send afurther notification to the HSS is triggered by detection of an eventrequiring an IMS registration change, for said given user, from the NotRegistered state to an Unregistered state.
 17. The method of claim 15,wherein said event comprises the receipt by the S-CSCF of a terminatingservice request in respect of said given user.
 18. A system comprising:a first apparatus configured to operate as a Serving Call SessionControl Function, S-CSCF, within an IP Multimedia Subsystem, IMS, corenetwork, the first apparatus comprising: an interface for sending to aHome Subscriber Server, HSS, of the IMS core network, notificationsindicating IMS registration state changes of users; a detector fordetecting delivery failure of a notification of an IMS registrationstate change sent to a HSS and relating to a given user; a memory andmemory controller for storing in said memory an association between anidentifier of said given user and an indication of said delivery failurein order to indicate a loss of IMS registration state synchronizationfor said given user between the S-CSCF and the HSS; and an event handlerfor: detecting an event relating to said given user, the event requiringan IMS registration state change for the user; determining that saidmemory currently stores a delivery failure indication associated withthe user's identifier; and causing said interface to send a furthernotification to the HSS, the further notification including both anindication of the required IMS registration state change and anindication of a previous loss of IMS registration state synchronizationfor the user between the S-CSCF and the HSS; and a second apparatusconfigured to operate as a Home Subscriber Server, HSS, within an IPMultimedia Subsystem, IMS, core network, the second apparatuscomprising: a memory for storing users' IMS registration states; aninterface for receiving from a Serving Call Session Control Function,S-CSCF, of the IMS core network, notifications indicating IMSregistration state changes of users to new IMS registration states; anda state synchronization handler for determining that a notificationreceived from the S-CSCF contains an indication of a previous loss ofIMS registration state synchronization for a given user between theS-CSCF and the HSS, and for responding by updating the given user's IMSregistration state in the memory to the new IMS registration statecontained in the received notification.
 19. A non-transitorycomputer-readable storage medium storing computer program instructionswhich, when executed by a processor in a Serving Call Session ControlFunction, S-CSCF, cause the processor to perform a method of handling acommunication failure between the S-CSCF and a Home Subscriber Server,HSS, of an IP Multimedia Subsystem, IMS, network, the method comprising:detecting delivery failure of a notification sent by the S-CSCF to theHSS and relating to an IMS registration state change for a given user;recording an indication of the delivery failure in association with saidgiven user in order to indicate a loss of IMS registration statesynchronization for the given user between the S-CSCF and the HSS;detecting an event relating to said given user, the event requiring anIMS registration state change for the user to a new state; determiningthat a delivery failure indication is currently associated with theuser; and sending a further notification to the HSS, the furthernotification including both an indication of the required IMSregistration state change and an indication of a previous loss of IMSregistration state synchronization for the user between the S-CSCF andthe HSS.
 20. A non-transitory computer-readable storage medium storingcomputer program instructions which, when executed by a processor in aHome Subscriber Server, HSS, cause the processor to perform a method ofhandling a communication failure between a Serving Call Session ControlFunction, S-CSCF, and the HSS of an IP Multimedia Subsystem, IMS,network, the method comprising: receiving, from the S-CSCF,notifications indicating IMS registration state changes of users to newIMS registration states; determining that a notification received fromthe S-CSCF contains an indication of a previous loss of IMS registrationstate synchronization for a given user between the S-CSCF and the HSS;and updating the given user's IMS registration state in the memory tothe new IMS registration state contained in the received notification.